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© The data transmission method employs IEEE 
P1394 protocol. The data header of the transmitted 
isochronous packet is added with a node identifier 
identifying the transmitter node, so that the receiver 
node can immediately identify the transmitter node, 
and can thereby request the transmitter node to 
maintain transmission. A Broadcast channel is a de- 
fault channel used for isochronous packet transmis- 
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sion, unless a different channel number is otherwise 
specified. Thus, it is not necessary for the user to 
coordinate the channel number used.by the transmit- 
ting and receiver nodes. It is also not necessary for 
the transmitter node to notify the receiver node, or 
the receiver node to notify- the transmitter node, of 
the channel number used. 
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BACKGROUND OF THE INVENTION 
1. Field of the invention 

The present invention relates to a system for 
transm.tt.ng audio signals and/or video signals as a 
digital s.gnal in such applications as a digital video 
cassette recorder (VCR) whereby audio signals 
and/or video signals are recorded and reproduced 
as d.g.tal signals, and also to a method thereof. 

2. Description of the prior art 

Devices for transmitting audio signals and/or 
video signals via a digital signal transmission path 
are being continually developed. Transmitting audio 
signals and/or video signals as a digital signal 
however, requires sending and receiving to be syn- 
chronized to the processing speed of the appara- 
tus, and therefore requires a transmission path 
capable of isochronous transmission. A bus con- 
nect.on is even more preferable considering the 
potential need for two-way communications on a 
single transmission path whereby plural devices 
can receive a signal transmitted from a single de- 
vice. . 

The Institute of Electrical and Electronic En- 
gineers. Inc. (IEEE) is currently studying a next- 
generation high speed serial bus protocol under the 
.tie P1394 (see "High Performance Serial Bus") 
Under the proposed IEEE P1394 standard, isoch- 
ronous transmission data, including audio signals 
video signals, and other real-time data, can be 
transmuted by isochronous transmission using 
isochronous packets, which are sent and received 
every 125 usee (= 1 cycle) to achieve isochronous 
transmission. 

The isochronous transmission control method 
of IEEE P1394 is described next. When the bus is 
.n.t.alized according to IEEE P1394, a node iden- 
tifier ,s automatically assigned to each device con- 
nected to the bus (each 'node') as a means of 
identifying each node. A maximum 64 isochronous 
packets per cycle can also be sent over the bus 
As a result, each isochronous packet is also as- 
signed a channel number ranging in value from 0 
to 63 to identify each isochronous packet To 
ach.eve isochronous transmission on plural chan- 
nels, one of the plural nodes connected to the bus 
.s used for .sochronous transmission management- 
this node is called the "bus manager" below. 

The bus manager manages the channel num- 
bers used for isochronous "transmission, and the 
time remaining in each cycle usable for isoch- 
ronous transmission. The time sharing rate or the 
time slot width,, required for each node to transmit 
an isochronous packet in one cycle is referred to 
as a bandwidth below. To achieve isochronous 



transmission, the bus manager must reserve the 
channel number and the bandwidth to be used It 
should be noted that communications not essential 
to isochronous transmission and information that 
5 does not require isochronous transmission are 
transmitted by asynchronous transmission using 
asynchronous packets. Asynchronous communica- 
tion .s accomplished using cycle time not used for 
isochronous transmission. 
'o The bus is also immediately reinitialized when- 

ever a node is connected or disconnected from the 
bus. or whenever any node on the bus is turned 
off, to enable active bus configuration. 

The first problem addressed by the present 
'5 invention is described next. 

When the IEEE P1394 high performance serial 
bus .s applied to isochronous transmission between 
consumer audio-visual (AA/) devices using the con- 
ventional isochronous packet described above it is 
20 not possible for the node receiving the isochronous 
packet to identify the node sending that isoch- 
ronous packet. 

Because of this node identification problem 
the node receiving the isochronous packet cannot" 
« request the node sending the isochronous packet 
to cont.nue isochronous packet transmission when 
it is necessary to prevent interruption of isoch- 
ronous transmission due to an unexpected user 
action, and it is therefore not possible .to set the 
30 transmission node to a protected state. 

This is described below referring to a system 
comprising nodes A, B, and C with node B as- 
sumed to be receiving and recording the isoch- 
ronous packet sent by node A. If the user then 
35 performs some action causing node C to transmit 
an isochronous packet, node C must request node 
A to stop transmitting the isochronous packet If 
node A responds to this request by stopping trans- 
mission, the recording operation of node B will be 
40 interrupted. It is therefore possible by this conven- 
tional data transmission method to interrupt the 
transmission of isochronous packets between com- 
municating nodes when one node not associated 
with that isochronous packet transmission, is ac- 
45 cdentally or improperly operated. 

The second problem is described next As 
described above, the IEEE P1394 protocol enables 
plural channels of real-time data' to be output dur- 
ing one cycle. It is therefore necessary for the 
so receiver node(s) to determine the channel numbers 
of the real-time data that should be received by 
that node. One method of enabling the receiver 
node to determine the channel numbers to be 
received is for the user to inform the receiver node 
55 of the channel numbers to be received. To do this 
however, the user must determine and inform the 
rece.ver node of the channel numbers of the real- 
time data that should be received, and this in- 
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creases the burden on the user. 
SUMMARY OF THE INVENTION 

Therefore, a data transmission method accord- 
ing to the present invention for resolving the first 
problem described above, a node identifier identify- 
ing the node transmitting the isochronous packet is 
added to each isochronous packet. 

To handle requests to continue transmission 
from a plurality of receiver nodes, the transmitter 
node enters a protected state when one or more 
continuation requests is received from one or more 
receiver nodes, and cancels the protected state 
when the number of "stop enable" flags received is 
at least equal to the number of continuation re- 
quests-received. 

By a data transmission method thus com- 
prised, the receiver node can immediately identify 
the node transmitting the isochronous packet by 
simply reading the node identifier of the transmitter 
node contained in each received isochronous pack- 
et. 

In addition, by identifying the transmitter node, 
the receiver node can send a continuation request 
to the transmitter node as may be required, and 
can send a stop enable flag when it is no longer 
necessary to continue transmitting. Each time the 
transmitter node receives a continuation request, 
the transmitter node increments a protect counter, 
and decrements the protect counter each time a 
stop enable flag is received. When the value of the 
protect counter is not zero, the transmitter node 
can prevent interruption of isochronous transmis- 
sion due to an unexpected user operation by re- 
jecting any stop transmission requests received 
from another node. 

A data transmission method for resolving the ; 
second problem of the prior art described above is 
described below. 

In this data transmission method for transmit- 
ting real-time data using a bus system capable of 
handling a plurality of channels of real-time data by 
adding the channel number of each data packet to 
the data in form of a channel identifier, the trans- 
mitter node comprises a step whereby the trans- 
mitter node obtains the Broadcast channel, which is 
a fixed channel N, and the bandwidth required to 
transmit the real-time data; a step for determining 
whether the Broadcast channel and the bandwidth 
have been obtained; and a step for starting real- 
time data transmission using the Broadcast channel ' 
and permitted bandwidth. The receiver node in this 
method comprises a step whereby receiving real- 
time data from the real-time data packet of the 
Broadcast channel is started. 

By this second invention, the channel number 
used by the A/V devices is fixed, and unless a 



different channel number is specified by an exter- 
nal device, this fixed, or default, channel number is 
used for data transmissions. In other words, unless 
the receiver node is specified by an external de- 

5 vice, it is possible for each A/V device to constantly 
receive all real-time datajransmitted on the Broad- 
cast channel. It is therefore not necessary for the.; 
user to inform the receiver node of the channel 
number to be received during isochronous trans- 

70 mission. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will become more fully 
75 understood from the detailed description given be- 
low and the accompanying diagrams wherein: 

Fig. 1 is a block diagram of plural audio/visual 
devices connected to a bus according to the : 
IEEE P1394 protocol; 
20 Fig. 2 is a block diagram of the internal configu- 
ration of each audio/visual device shown in Fig. 
1; 

Fig. 3 shows the isochronous packet format de- 
fined by IEEE P1394; 
25 Fig. 4 shows the format of the packet header of 
the isochronous packet defined by IEEE P1394; 
Fig. 5 shows the asynchronous packet format 
defined by IEEE P1394; 

Fig. 6 shows the format of the packet header of 
30 the asynchronous packet defined by IEEE 

P1394; 

Fig. 7 shows the isochronous packet format ac- 
cording to the first embodiment of the present 
invention; 

35 Fig. 8 is a block diagram of a VCR connection 

according to the second embodiment of the 
present invention; 

Fig. 9 is a flow chart of the reproduction process?; 
of a VCR according to the second embodiment 
40 of the present invention; 

Fig. 10 is a flow chart of the recording process;;- 
of a VCR according to the second embodiment 
of the present invention; 

Fig. 11 is a block diagram of the control block in 
45 the second, third and fourth embodiments of the. 

present invention; ■ *■ • : 

Fig. 12 is a flow chart of the communications 
management block when transmission is started; 
by the second embodiment of the 1 invention; 
so Fig. 13 is a flow chart of the communications 

management block when receiving is started by 
the second embodiment of the invention; 
Fig. 14 shows the format of the data block in the 
isochronous packet according to the third and 
55 third embodiments of the present invention; 

Fig. 15 is a flow chart of the communications 
management block when transmission is started 
by the third embodiment of the invention; 
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Fig. 16 is a flow chart of the communications 
management block when transmission is stop- 
ped by the third embodiment of the invention; 
Fig. 17 is a flow chart of the communications 
management block when transmission is started 
by the fourth embodiment of the invention; 
Fig. 18 is a flow chart of the communications 
management block when transmission is stop- 
ped by the fourth embodiment of the invention; 
Fig. 19 is a flow chart of the communications 
management block when isochronous transmis- 
sion to another node is commanded by the fifth 
embodiment of the invention; and 
Figs. 20 and 21 are flow charts of the commu- 
nications management block when, isochronous 
transmission is commanded by another node 
according to the fifth embodiment of the inven- 
tion. 

DESCRIPTION OF PREFERRED EMBODIMFMT.q 
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The present invention relates to a transmission 
procedure for transmitting real-time data such as 
audio/visual data using the P1394 protocol cur- 
rently being considered by the Institute of Electrical 2 s 
and Electronic Engineers, Inc. Fig, 1 shows a plu- 
rality of audio/visual devices connected to a bus 
according to the IEEE P1 394 protocol. In this ex- 
ample, four audio/visual devices are connected to a 
common bus, and the devices are referred to as 30 
nodes. A/V devices 101, 102, 103, and 104 are 
connected by a cable 105 which serves as a bus 
structure: 

The A/V devices 101 - 104 have a similar 
control arrangement which is shown in Fig. 2 by 35 
way of example for A/V device I02i Each A/V 
device comprises an interface block 201, an A/V 
signal processing block 202, and a control block 
203. Signals from the other nodes are input to one 
A/V device 102 through the interface block 201. In 40 
the interface block 201, -the input signals have their 
waveform shaped, and the. waveform-shaped sig- 
nals are output to the next A/V device 103. The 
interface block 201 is capable of transmitting the 
output signals from any other /W device, i.e., any 45 
other node when connected according to the IEEE 
P1394 protocol as shown in Fig. 1, to all other A/V 
devices (nodes). 

In the IEEE P1394 protocol, real-time data is 
transmitted using isochronous packets, the format 50 
of which is shown in Fig. 3 as defined by IEEE 
P1394. 

Each isochronous packet comprises a 4-byte 
packet header 301; a 4-byte header CRC 302 for 
checking for transmission errors in the packet 55 
header 301; a data block 303; and a 4-byte data 
CRC 304 for checking for transmission errors in the 
real-time data. 



The format of the packet header 301 is shown 
in Fig. 4. As shown in Fig. 4. the packet header 
301 includes the channel number 401. According to 
the IEEE P1394 protocol, plural A/V devices 
(nodes) can transmit plural isochronous packets on 
a time-share basis approximately every 1 25 usee 
(= 1 cycle). The channel number 401 is added to 
the isochronous packets for identifying each packet 
transmitted during the same cycle. 

When transmitting real-time data, the control 
block 203 instructs the A/V signal processing block 
202 to output the real-time data, including the 
audio/visual data. Based on the instructions from 
the control block 203, the A/V signal processing 
block 202 therefore outputs the real-time data. The 
control block 203 also adds the channel number 
used and other information, and controls isoch- 
ronous packet output to the interface block 201 . 

Based on the instructions from the control 
block 203, the interface block 201 -packetizes the 
real-time data from the A/V signal processing block 
202 as the data block 303 shown in Fig. 3 accord- 
ing to the packet format also shown in Fig. 3. The 
interface block 201 then outputs the isochronous 
packet to the other nodes (A/V devices). 

When receiving realtime data, the control 
block 203 informs the interface block 201 of the 
channel number of the isochronous packets to be 
received. The interface block 201 then detects the 
channel number of each isochronous packet from 
the packet header. If the detected channel number 
is the specified channel number, the interface block 
201 outputs to the A/V signal processing block 202 
the real-time data contained in the data block 303 
from the isochronous packet shown in Fig. 3. The 
control block 203 also controls input of the real- 
time data to the A/V signal processing block 202, 
which signal processes the input data.; 

It is therefore possible for plural nodes to trans- 
mit plural isochronous packets during the same 
cycle by the IEEE P 1394 protocol as described 
above, i.e., plural isochronous transmission be- 
tween plural nodes can be accomplished in an 
apparently simultaneous manner. It is necessary, 
however, to reserve sufficient bandwidth for the 
internal processing speed of each node with each 
isochronous transmission. Here, the bandwidth 
means a width of a reserved time slot in each 
cycle of. 125 usee, and various : time, slots in each 
cycle are distinguished by different channel num- 
bers. According to the IEEE P1394 protocol, it is 
possible to use, at the maximum, 64 different chan- 
nel numbers, from 0 to 63. Because the maximum 
transmittable bandwidth is limited (obviously less 
than 125 usee), it is necessary to manage the 
bandwidth used by each node. In addition, a chan- 
nel number is added to each isochronous packet to 
identify each isochronous packet and thereby en- 



*SOOClD: <EP 0682430 A2> 



7 



EP 0 682 430 A2 



8 



able isochronous transmission of data on plural 
channels. Managing the channel numbers used by 
each node is necessary to prevent the same chan- 
nel number from being assigned to packets on 
different channels when plural nodes simultaneous- 5 
ly output isochronous packets. This channel num- 
ber duplication is prevented in the IEEE P1394 
protocol by dedicating one node as a bus manager 
for centrally controlling bandwidth and channel 
numbers. A/V devices or other node devices ex- w 
ecuting isochronous transmission must receive 
from the bus manager the specific bandwidth and 
channel number used by that node for isochronous 
transmission. Note that the "used bandwidth" de- 
fines the amount of time in each cycle that the 75 
node outputting the isochronous packet can mo- 
nopolize the bus to send the isochronous packets. 

Communications other than the isochronous 
transmission described above, e.g., communica- 
tions for obtaining the used bandwidth and channel 20 
number, are accomplished by asynchronous trans- 
mission using asynchronous packets. Asynchro- 
nous transmission is accomplished using the cycle 
time remaining after isochronous transmission is 
completed in each cycle. Fig. 5 shows the asyn- 25 
chronous packet format defined by IEEE Pi 394. 

Each asynchronous packet comprises a 16- 
byte packet header 501; a 4-byte header CRC 502 
for checking for transmission errors in the packet 
header 501; an asynchronous data body 503; and a 30 
4-byte data CRC 504 for checking for transmission 
errors in the asynchronous transmission data. The 
packet header 501 comprises a receiver node iden- 
tifier 601, which is the identifier of the node to 
which the transmitted asynchronous packet is ad- 35 
dressed, and a transmitter node identifier 602, 
which is the identifier of the node transmitting the 
packet. The receiver node identifier 601 and the 
transmitter node identifier 602 in the packet header 
are each two bytes long. The receiver node re- 40 
ceives all asynchronous packets in which the value 
of the receiver node identifier 601 is equal to the 
node identifier of the receiver node. The receiver 
node can also determine by the transmitter node 
identifier 602 in the received asynchronous packets 45 
which node sent the asynchronous packet by read- : 
ing the transmitter node identifier 602. 

The procedure for asynchronous transmission 
is described next. To send an asynchronous pack- 
et, the control block 203 instructs the interface 50 
block 201 to asynchronously transmit the asyn- 
chronous transmission data after appending the' 
receiver' node' identifier identifying the addressed 
node. The interface block 201 thus generates and 
outputs the asynchronous packets from the asyn- 55 
chronous data, receiver node identifier, and other 
information input from the control block 203. When 
an asynchronous packet is received, the interface 



block 201 identifies the asynchronous packets ad- 
dressed to that node by evaluating the receiver 
node identifier 601 contained in the packet header 
501, and outputs the asynchronous data 503 and 
the transmitter node identifier 602 from the re- 
ceived asynchronous packet to the control block 
203. The control block 203 then executes the re-, 
quired processing based on the asynchronous data 
input thereto. - 

Referring to Figs. 7 to 10, the first embodiment 
of the present invention is described below. Note 
that the first embodiment is described with specific 
application to a video cassette recorder (VCR) as 
the A/V device. 

Fig. 7 shows the format of an isochronous^ 
packet transmitted during isochronous transmission 
by the first embodiment of the invention. 

Referring to Fig. 7, data block 303 is used to 
communicate any data the user wishes to commu- 
nicate, and comprises a data header 702 identify- 
ing the type of data transmitted in that isochronous 
packet, and the A/V data 703 actually transmitted. 
The data header 702 comprises the node identifier 
1101 identifying the node that transmitted that 
isochronous packet, and other header data. Thus, 
by detecting and reading the node identifier 1101 
at the receiver node, it is possible to detect who is 
the transmitter node. 

When a new node is connected and a bus 
reset is generated according to the IEEE P1394 
protocol, a new node identifier is automatically as- 
signed to that newly connected node. As a result, 
the node transmitting the isochronous packet writes 
the node identifier assigned thereto to the data 
header 702 according to the format shown in Fig. 
7, and then transmits the isochronous packet. 

Fig. 8 shows how five VCRs may be connected 
for dubbing A/V data. The operation of each of the 
five VCRs 1201 - 1205 is controlled by the control 
block 203 built in to each VCR. Note that the: 
control block 203 of the present invention is 
achieved by a microcomputer. The VCRs 1201 - 
1205 are connected by connector cables 1205. 
Each time a cable is connected, a 'bus reset' 
command is generated to assign the node identifi- 
ers to the VCRs 1201 - 1205v Node identifiers 
(node_ID) 0-4 are assigned to VCRs 1201 - 
1205, respectively, by way of example only in the 
following description. 

As noted above, packet sending and receiving 
is executed on a 125 usee cycle according to the 
IEEE P1394 protocol, and the first half of each 
cycle can be. assigned to a priority time band for 
isochronous transmission. It is therefore necessary 
to reserve the bandwidth required within the finite 
priority time band reserved for isochronous trans- 
mission. More specifically, it is necessary to first 
determine which communications channel is to be 
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used for what length of time for isochronous packet 
transmission. Managing this priority time band is 
also handled by the node used as the bus manager 
node 1204. 

It is assumed in the following description that 5 
A/V data reproduced by the first VCR 1201 is to be 
dubbed by VCRs 1202 and 1203, and that VCR 
1204 is the bus manager node managing the prior- 
ity time band. (VCR 1205 will be used for the 
description of the second embodiment.) The ex- 
ecution of the present embodiment is described 
below by these three function blocks. Data other 
than the A/V data used in the following description, 
e.g. continuation requests and stop enable flags 
sent from the receiver node to the transmitter node, 
are communicated using asynchronous packets. In 
the control block 203 of VCR 1201 serving as a 
play device, a counter 1201a is provided. In the 
control block 203 of VCRs 1202 and 1203 each 
serving as a recording device, up/down command ; 
generators 1202a and 1203a are provided, respec- 
tively. The up/down command generator 1202a or. 
1203a generates an up command, it means that the 
VCR 1202 or 1203 will continue to stay in the 
recording mode, and when it generates a down £ 
command, it means that the VCR 1202 or 1203 is 
released from the recording mode. For example, 
when the up/down command generator 1 202a gen- 
erates an up command, the counter 1201a which 
was before in the reset condition, is incremented 3 
from "0" to "1" indicating that there is one VCR 
which will continue to record the data sending from 
this player 1201. Thereafter, when the up/down 
command generator 1203a generates an up com- 
mand, the counter 1201a now carrying w 1 " is incre- 3, 
mented to "2" indicating that there is two VCRs 
which will continue to record the data sending from 
this player 1201. Thereafter, when the up/down 
command generator 1203a generates a down com- 
mand, the counter 1201a now carrying "2" is de- 4i 
cremented to "2" indicating that there is. one VCRs 
which will continue to record the data sending from 
this player 1201. When the counter 1201a is carry- 
ing a number other than "0", such as "1" or "2V t 
the player 1201 is :in a protect mode r so that the, 45 
play mode will not be stopped by an internal stop 
command, but. stops only by an external stop com- 
mand. Here, the internal stop command is a com- . 
mand transmitted along the bus from some other; 
VCR; and the external stop command is a com 50 
mand given directly by hand to the VCR, such- as 
by the depression of a STOP button (not shown), ' 
or by the power cut off. The up command can be 
considered as a continuation request to continue 
the play mode of the player, or a protect transmis- 55 
sion request to protect the transmission of play 
until all the recording VCRs stop recordings 



Fig. 9 is a flow chart of the process executed 
by the control block 203 in the first play VCR 1201 
during the play process whereby the VCR 1201: 
reproduces the A/V data; requests from the bus 
manager 1204 the bandwidth required for isoch- 
ronous transmission; receives permission to trans- 
mit; and then actually transmits the isochronous 
packet. Note, also, that the play VCR 1201, serving 
as a transmitter node,, first .writes the assigned 
node identifier "0" to the node identifier 1101 of 
the data header 702 according to the isochronous 
packet format shown in Fig, 7 before commencing 
isochronous packet transmission. 

In the first step 1301, the node attempting- to : 
transmit determines whether an up command (a 
continuation request) has been received from any 
one of the other nodes. If an up command was 
received, the protect counter 1201a, which is a 6- 
bit counter set in memory, is incremented (step 
1302); if an up command was not received, control 
skips to step 1 303. 

Note that the protect counter 1201a is reset to 
"0" immediately before isochronous packet trans- 
mission begins. As a result, if an up command is 
received from each of the other two VCRs 1202 
and 1203 after the first VCR 1201 begins isoch- 
ronous packet transmission, the protect counter 
1201a in the first VCR 1201 will have a value of 

In step 1303, it is determined whether a down 
command (a stop enable flag) was received from 
one of the other nodes. If a down command was 
received, the protect counter 1201a is decremen- 
ted (step 1304); if not received, control skips to the 
next step 1 305. 

If, for example, an up command is received 
from the other two VCRs 1202 and 1203 and the 
protect counter 1201a in. the transmitting VCR 1201 
is tt 2, n ,the protect counter will not be reset to "0" 
again until both the other two VCRs 1202 and 1203 
produces a down command to the transmitting 
VCR 1201. 

Note, also, that the protect counter is not de- 
cremented in step 1304 even if a down command 
is received if the value of the protect counter is 
already "0." 

In step 1305, it is determined whether a bus 
reset has been generated; if it has, the - protect 
counter is reset to "0" (step 1306), and control 
loops back to step 1301. If a bus reset has not 
been, generated; control advances to step 1307: 

Isochronous packet transmission is temporarily 
interrupted when a bus reset occurs, but the trans- 
mitting VCR 1201 immediately resumes isochron- 
ous packet output after recovering from the bus 
reset operation. 

Bus resets may occur when a connector is 
connected or disconnected, or when the power 



11 



EP 0 682 430 A2 



12 



supply to one of the bus devices is interrupted. As 
a result, any node that sent an up command before 
the bus reset occurred is disabled from sending 
the down command once a bus reset occurs. In 
this case, the transmitting VCR 1201 cannot re- 
cover from the protected state. It is therefore nec- 
essary to reset the protect counter whenever a bus 
reset occurs. 

In step 1307, it is determined whether an asyn- 
chronous packet transmission with an interna! stop 
command has been received from any node, e.g., 
the bus manager node 1204. If it has, it is deter- 
mined whether the protect counter 1201a is "0" 
{step 1308). 

If the protect counter is any value other than 
"0" at this time, transmission is protected, the 
internal stop command is therefore not accepted 
(step 1309), an internal stop command rejection 
notice is output to the node 1204 that has sent out 
the internal stop command, and control loops back 
to step 1301. 

If the protect counter value is "0", transmission 
is not protected, the internal stop command is 
accepted, isochronous packet transmission is stop- 
ped (step 1310), and processing terminates. 

If an asynchronous packet transmission with an 
internal stop command has not been received in 
step 1307, it is determined whether an external 
stop command has been received directly from an 
external source (step 1311) without communication 
via the bus. Examples of the external stop com- 
mands received directly from an external source 
include user operation of a STOP SENDING func- 
tion button provided on the VCR 1201, and press- 
ing a power supply switch turning the power off. 

When an external stop command is received in 
step 1311, the protect counter 1201a is imme- 
diately reset to 0 irrespective of the current counter 
value (step 1312), and isochronous packet trans- 
mission is stopped (step 1310). In other words, 
direct user operation of the device is given priority. 

In a transmitting apparatus comprising a digital 
output button controlling enabling and disabling the 
output of data to the bus, a direct external stop 
command may also be generated by the user 
operating the digital output button during isoch- 
ronous packet transmission to disable data output. 

In a dedicated reproduction device wherein 
digital signal output stops when reproduction stops 
because there is no built-in television tuner, a di- 
rect external stop command may also be gen- 
erated by pressing the stop button to stop re-' 
production and enter the stop mode. 

When a direct external stop command is not 
received in step 1311, control loops back to step 
1301 and the entire process is repeated. 

Fig. 10 is a flow chart of the process executed 
by the control block 203 of the receiving VCRs 



1 202 and 1 203 after recording the A/V data isoch- 
ronous packet actually received from the transmit- 
ting VCR 1201 begins. 

It is assumed in the description of the present 

5 embodiment below that the bus manager node 
1204 is accidentally set to the reproduction mode 
by a user operation during dubbing by the receiv- 
ing VCRs 1202 and 1203 of the A/V data repro- 
duced by the first VCR 1-201. In this case, if the 

10 bus manager node 1204 cannot output the isoch- 
ronous packet, it sends an internal stop command 
asking the transmitting VCR 1201 to stop output- 
ting the isochronous packets. 

Even in such a condition as explained above, 

;5 according to the first embodiment, the A/V data- 
recording VCRs 1202 and 1203 continues to cor- 
rectly dubbing the received A/V data without trans- 
mission thereof from the first VCR 1201 being 
interrupted. In other words, in response to the 

20 receipt of the isochronous packet from the trans- 
mitting VCR 1201, the recording VCRs 1202 and 

1203 send an up command to that VCR 1201 to 
increment the counter and eventually starting the 
interruption protect state. In addition, it should be 

25 noted that recording VCRs 1202 and 1203 execute 
the same process in this embodiment, and only the 
process executed by the one VCR 1202 is de- 
scribed below. 

Referring to Fig. 10, the node identifier "0" of 

30 the transmitter node 1201, which is written to the 
data header 702 of the received isochronous pack- 
et as described above, is read in step 1401, and an 
up command is sent to the node identified by that 
node identifier "0", i.e., to the transmitter node 

35 1201. Control then advances to step 1402. 

In step 1402, it is determined whether a bus 
reset was generated; if it was, control loops back to 
step 1401 to re-request transmission protection. ~, 
If a bus reset did not occur, it is determined 

40 whether isochronous packet receiving is normal 
(step 1403). For example, because the play VCR 
1201 is set to the transmission stop state (step 
1310), it may be determined whether isochronous 
packet receiving is interrupted. 

45 When isochronous packet receiving is normal, 

control advances to the next step 1404, but if 
receiving is not normal, the process terminates. 

In step 1404 it is determined whether a "stop 
recording" instruction was received; if it was not, 

so control loops back to step 1402, and the loop is 
repeated to monitor any. bus reset instructions until 
a "stop recording" instruction is received. 

When the "stop recording" instruction is re- 
ceived, the node identifier 1101 of the transmitter 

55 node 1201 written to the data header 702 of the 
received isochronous packet as described above is 
again read, and a down command is sent to the 
transmitter node identified by that node identifier 
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1 101 in step 1405 to end the process. 

As described in the first embodiment above, 
the transmitter node 1201 writes and transmits the 
node identifier assigned to itself in the data header 
702 of the transmitted isochronous packet, thereby 
enabling the nodes 1202 and 1203 receiving this 
isochronous packet to immediately identify the 
node 1201 that transmitted that packet. 

Furthermore, the transmitter node 1201 incre- 
ments the protect counter at the point an up com- 
mand is received from, for example, the receiver 
node 1202 or 1203; decrements the protect counter 
when a down command is received; and is in a 
protected state when this protect counter is any 
value other than "0." When the transmitter node 
1201 is protected, it rejects any stop transmission 
requests received from another node, e.g., from the 
bus manager node 1204, and continues transmit- 
ting. As a result, even when the bus manager node 
1204 is accidentally set to the reproduction mode 
by a user operation during dubbing* by the receiv- 
ing VCRs 1202 and 1203 of the A/V data repro- 
duced by the first VCR 1201, dubbing continues 
normally without transmission of the isochronous 
packets from the first VCR 1201 to the A/V data- 
recording VCRs 1202 and 1203 being interrupted. 

In addition, by resetting the protect counter 
when a bus reset occurs, it is possible even when 
a bus reset occurs to prevent the transmitter node 
1201 from not being able to recover from the 
protected state, a situation which could otherwise 
occur because any node that transmitted a continu- 
ation request before the bus reset occurred is 
disabled by the bus reset from issuing the stop 
enable flag. 

It is to be noted that the receiver node sending 
a up command to the transmitter node in the 
embodiment described above need not be the 
node recording the isochronous packets from the 
transmitter node. For example, a television monitor 
("TV" below) and a laser disk player ("LD player" 
below) could be connected to the bus with the 
reproduction image from the LD player viewed on 
the TV. In. this case the user could operate control 
button(s) on the TV, which in this application is the 
receiver node, to send an up command to the LD 
player, which in this application is the transmitter 
node, to maintain reproduction image transmission 
from the LD player to the TV and , prevent re- 
production images from some other device con- 
nected to the same bus from being accidentally 
displayed on the TV. 

Also in the above embodiment the transmitter 
node is set to a protected state when an up com- 
mand is received thereby from a receiver node, but 
it is to be noted that this protected state can also 
be set by inputting a "continue transmission" in- 
struction directly from an external device rather 



than through the bus system. For example, in the 
above TV and LD player example, a PROTECT 
function button could be provided on the LD player 
(transmitter node) for setting the LD player to the 
5 protected state by simply operating this PROTECT 
button. 

In addition, a counter provided in memory is 
used as the means for determining whether the 
transmitter node is in the projected or protection- 
w cancelled state, but any other means of determin- 
ing whether the transmitter node is in the protected 
or protection-cancelled state may be alternatively 
used. For example, it is alternatively possible to 
use a register having only as many bits as the 
?5 number of connectable nodes. 

By the data transmission method of the present 
invention as described above, when transmitting 
A/V data requiring real-time processing by isoch- 
ronous packets using a bus system whereby a 
20 node identifier is automatically assigned to each 
node connected to the bus whenever a bus reset 
occurs, it is also possible by adding the node 
identifier of the transmitter node to the isochronous 
packets before transmission for the receiver node 
25 to immediately determine which node transmitted 
the received isochronous packets; this can be ac- 
complished by simply reading the transmitter node 
identifier included in the received isochronous 
packets. 

30 Furthermore, by identifying the transmitter 

node, the receiver node can as required send to ~ 
the transmitter node an up command requesting 
sustained transmission of the isochronous packets; 
and send a down command requesting cancellation 

35 of the up command when it is no longer necessary 
to continue the transmission. The node transmitting 
said isochronous packets is thus set to a protected 
state when one or more up commands is received, 
and cancels the protected state when the number 
40 of down commands received by the transmitter 
node exceeds the number of received up com- 
mands. 

When the transmitter node is in the protected 
state, internal stop commands received from any 
45 node are rejected, and isochronous packet trans- 
mission does not stop (is continued). As a result, 
interruption of isochronous transmission due to ac- 
cidental or mistaken operation by the user can be 
prevented. 

so More specifically, it is possible to prevent 

isochronous packet transmission between any giv- 
en nodes from being interrupted as a result of 
misoperation of any node not directly associated 
with that isochronous packet transmission opera- 

55 tion. This is particularly effective during dubbing 
and other isochronous transmission operations dur- 
ing which communication may be sustained for a 
relatively long period of time. 
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In addition, by automatically resetting any pro- 
tected-state transmitter node to the protection-can- 
celled state whenever a bus reset occurs, it is 
possible even when a bus reset occurs to prevent 
the transmitter node from not being able to recover 
from the protected state, a situation which could 
otherwise occur because any node that transmitted 
an up command before the bus reset occurred is 
disabled by the bus reset from issuing the down 
command. 

The second embodiment of a data transmis- 
sion method according to the present invention is 
described below. 

In conventional data transmission methods for 
isochronous transmission using the IEEE P1394 
protocol, the transmitter node selects an unused 
channel number in the range from 0 - 63, inclusive, 
and adds the selected channel number to the pack- 
et header in the isochronous packet before trans- 
mission. The transmitter node must also simulta- 
neously inform the user of the* channel number 
used for transmission. Because there may be plural 
isochronous packets transmitted on different chan- 
nels, the user must therefore inform the receiver 
node of the channel number of the isochronous 
packets to be received. Isochronous packet trans- 
missions by the method of the prior art thus re- 
quires user intervention to match the channel num- 
ber used by the transmitting and receiver nodes, 
significantly increasing the user burden. 

The object of the second embodiment of the 
present invention is to enable packet transmission 
using . a Broadcast channel, i.e., a preselected 
channel with a predetermined channel number N 
(N is an integer between 0 and 63 inclusive), un- 
less the transmitter node specifies the use of a 
different channel number. The Broadcast channel is 
also called a default channel. 

A block diagram of the control block 203 used 
in this embodiment is shown in Fig. 11. The com- 
mand interpreter 1501 interprets operating com- 
mands received as a result of direct user control or 
asynchronous transmission from another node, and 
instructs the communications manager 1502 to be- 
gin and end isochronous and asynchronous trans- 
mission. 

The input to the communications manager 
1502 includes instructions from the command inter- 
preter 1501, and information input by asynchronous 
transmission from other nodes and required for 
communications management; Based on the input 
information, the communications manager 1502 in-' 
structs the interface block 201 and the A/V signal 
processing block 202 when to begin and end 
isochronous transmission; outputs the information 
required for communications management of the 
other nodes to the interface block 201 as asyn- 
chronous data; and simultaneously instructs the 



interface block 201 to output that information by 
asynchronous transmission. 

The procedure whereby the transmitter node 
begins isochronous packet transmission by the 

5 data transmission method according to this second 
embodiment is described next. 

The user first instructs the A/V device that is 
the transmitter node to output the AA/ data by the 
user operation. This instruction is input to the com- 

10 mand interpreter 1501 of the control block 203; the 
information instructing output of the real-time data 
on the Broadcast channel is extracted by the com- 
mand interpreter 1501 from the input instruction; 
and the extracted information is input to the com- 

15 munications manager 1502. The communications 
manager 1502 then executes control to begin :out- 
putting the real-time data using the Broadcast 
channel. 

Fig. 12 is a flow chart of the operation of the 

20 communications manager block in the transmitter 
node. The communications manager 1502 ex- 
ecutes step 1601 when real-time data output using 
the Broadcast channel is instructed by the com- 
mand interpreter 1501. At step 1601, the commu- 

25 nications manager 1502 instructs the interface 
block 201 to obtain or reserve from the bus man- 
ager the Broadcast channel and the usable band- 
width thereof. Based on this instruction, the inter- 
face block 201 negotiates with the bus manager 

30 1204 using asynchronous transmission to obtain an 
acceptance for the reservation of the necessary 
bandwidth and the Broadcast channel. The inter- 
face block 201 then notifies the communications 
manager 1502 in the control block 203 whether the 

35 Broadcast channel and the requested bandwidth 
were obtained. 

After executing step 1601, the communications 
manager 1 502 advances to step 1 602 to determine 
from the information input from the interface block 

40 201 whether the Broadcast channel and the. re- 
quested bandwidth were reserved. If the reserva- 
tions were accepted by the bus manager 1 204, 
control advances to step 1603; if not, control loops 
back before step 1601 and the communications 

45 manager 1502 reattempts to reserve the Broadcast 
channel and the requested bandwidth. 

In step 1603, the communications manager 
1502 instructs the AA/ signal processing block 202 
to output to the interface block 201 the A/V data 

so and other real-time data. The A/V signal processing 
block 202 then outputs this real-time data to the 
interface block 201. The communications manager 
1502 also instructs the interface block 201 to out- 
put the real-time data input from the A/V signal 

55 processing block 202 by isochronous packets us- 
ing the Broadcast channel. The interface block 201 
thus outputs the isochronous packets as instructed 
by the communications manager 1 502. 
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The procedure whereby the receiver node be- 
gins receiving isochronous packets by the data 
transmission method according to this third em- 
bodiment is described next. 

The user first instructs the A/V device that is 
the receiver node to receive the A/V data. This 
instruction is input to the command interpreter 

1501 of the control block 203, the information in- 
structing input of the real-time data on the Broad- 
cast channel is extracted by the command inter- 
preter 1501 from the input instruction, and the 
extracted information is input to the communica- 
tions manager 1502. The communications manager 

1502 then executes controls for receiving the real- 
time data using the Broadcast channel. 

Fig.. 13 is a flow chart of the operation of the 
communications manager block in the receiver 
node. The communications manager 1502 ex- 
ecutes step 1701 when real-time data receiving 
using the Broadcast channel is instructed by the 
command interpreter 1501. At step ~1 701, the com- 
munications manager 1502 instructs the interface 
block 201 to receive the isochronous packets on 
the Broadcast channel. 

Based on this instruction, the interface block 

201 receives the isochronous packets to which the 
Broadcast channel has been assigned, and outputs 
the real-time data to the A/V signal processing 
block 202. Also in step 1701, the communications 
manager 1502 instructs the A/V signal processing 
block 202 to receive the real-time data from the 
interface block 201 and execute the appropriate 
signal processing. The A/V signal processing block 

202 therefore receives the real-time data from the 
interface block 201 and executes signal processing 
as instructed by the communications manager 
1502. 

It is therefore possible by the second embodi- 
ment of a data transmission method according to 
the present invention to accomplish isochronous 
transmission, with the user simply instructing the 
transmitter node and receiver node(s) to output and 
input, respectively. It is therefore not necessary for 
the user to inform the receiver node of the channel 
number used, and a more user-friendly system 
reducing the burden on the user can be achieved. 

The third embodiment of a data transmission 
method according to the present invention relates 
to the isochronous transmission start and stop pro- 
cedures executed by nodes A and B when node A 
is transmitting by isochronous transmission and 
node B is then substituted for node A to continue 
transmission by isochronous transmission, such as 
when editing two tapes into one tape. 

The following procedure is typically executed 
to change the transmitter node in data transmission 
methods according to the prior art. To stop trans- 
mission by node A during isochronous transmission 



by node A, the user operates node A to- stop 
transmission. When node A thus receives a "stop 
transmission" instruction from the user, node A 
stops outputting isochronous packets, and releases 
s the channel number and used bandwidth to the bus 
manager. The user then instructs node B acquire a 
channel and to commence output using the ac- 
quired channel. In this case, node B must commu- 
nicate with the bus manager, to obtain an accep- 
w tance from the bus manager to use a new channel 
and a bandwidth before starting the isochronous 
transmission, which is the follow-up of the node A's 
isochronous transmission. As described above, it is 
necessary for the user to separately operate both 
is nodes A and B. In addition, both node A and node 
B must separately communicate asynchronously 
with the bus manager, thus increasing bus traffic. 

The data transmission method of the third em- 
bodiment of the present invention resolves this 
20 problem as follows. When node A, such as play 
device 1201 in Fig. 8, is transmitting by isoch- 
ronous transmission using the Broadcast channel 
described above, the present embodiment controls 
node B, such as play device 1205 in Fig. 8, to 
25 begin isochronous packet transmission using the 
Broadcast channel in place of node A. According to 
the third embodiment, the node, identifier of the 
transmitter node is written to each isochronous 
packet before the packet is. output, so that the node 
30 transmitting the isochronous packets can be deter- 
mined by simply receiving the isochronous pack- 
ets. One example of the data format in the data 
block 303 of the isochronous packets according to 
this embodiment is shown in Fig. 14. 
35 The transmitter node identifier 1801, which is 

simply the node identifier of the transmitter node, 
is added to the data block 303. In this example the 
real-time data 1802 is added after the transmitter 
node identifier 1801. It is also possible to place a 
40 data header 702 at the beginning of the data block 
303 as shown in Fig. 7, and write the node iden- 
tifier 1101 to that data header. The real-time data 
1802 is input from or is output to the A/V signal 
processing block 202. 
45 The procedure whereby node B begins isoch- 

ronous transmission according to this embodiment 
is. described below. 

Fig. 15 is a flow chart of the operation of the 
communications manager 1502 in the control block 
so 203 of node B. When the user instructs node B to 
begin isochronous transmission by operating either 
node B or another node, the user command is 
relayed to the communications manager 1502 via 
the command interpreter 1501 in the control block 
55 203 of node B. When the communications manager 
1502 receives the user command, it instructs the 
interface block 201 to receive isochronous packets 
from the Broadcast channel (step 1901). When the 
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interface block 201 receives an isochronous packet 
of the Broadcast channel, it detects the transmitter 
node identifier 1801 added to the received packet, 
and reports the detected node identifier to the 
communications manager 1502 in the control block 
203 (step 1902). 

Further more, in step 1902, the node identifier 
of the node transmitting the isochronous packets 
on the Broadcast channel is input from the inter- 
face block 201, node B recognizes that isoch- 
ronous packets have been transmitted from node A 
through the Broadcast channel, and control ad- 
vances to step 1903. 

In step 1903, the interface block 201 is in- 
structed by the communications manager 1502 to 
send a "stop output request" to node A, and the 
interface block 201 therefore sends a "stop output 
request" to node A using asynchronous packet 
transmission. In step 1903', it is detected whether 
or not the node A has rejected ^the "stop output 
request". When output from node. A is not com- 
pleted, node B is notified that node A has rejected 
the "stop output request" (step 2005). If it has, the 
control ends, but if not, the control advances to 
step 1904. 

In step 1904, it is determined whether a "used 
bandwidth" used by node A was received, or not. 
When node A stops output, node B is notified of 
the bandwidth used by node A after transmission 
stops (step 2004). 

When the interface bfock 201 of node B re- 
ceives an asynchronous packet containing either 
the "used bandwidth" of node A or rejection notice 
of the "stop output request", it informs the commu- 
nications manager 1502 of the received informa- 
tion. When the communications manager 1502 of 
node B is informed by the interface block 201 of 
the used bandwidth, control advances to step 1905. 

In step 1905, it is determined whether the used 
bandwidth of node A and the bandwidth scheduled 
for use by node B are equal. If they are, control 
advances to step 1906. 

In step 1906, the A/V signal processing block 
202 and interface block 201 are controlled to out- 
put the real-time data by Broadcast channel isoch- 
ronous packets. The A/V signal processing block 
202 thus outputs the real-time data to the interface 
block 201, and the interface block 201 outputs the 
isochronous packets, as instructed by the commu- 
nications manager 1502. 

If in step . 1905 the used bandwidth of node A 
and the bandwidth scheduled for use by node B' 
are determined to not be equal, the communica- 
tions manager 1502 branches to step 1907 and 
instructs the interface block 201 to request the bus 
manager to change the bandwidth. The interface 
block 201 thus negotiates with the bus manager 
1204 using asynchronous transmission to change 



the used bandwidth, and informs the communica- 
tions manager 1502 whether the used bandwidth 
was successfully changed. 

At step 1908, the communications manager 

5 1502 determines whether the used bandwidth was 
successfully changed; if it was not, the interface 
block 201 is instructed to release to the bus man- 
ager the Broadcast channel and the bandwidth 
used by node A (step 1910). If the used bandwidth 

10 was successfully changed (step 1908), the. AA/ 
signal processing block 202 and interface block 
201 are instructed to output the real-time data 
using isochronous packets assigned the Broadcast 
channel (step 1909). Following the instructions from 

75 the communications manager 1502, the A/V signal 
processing block 202 outputs the real-time data to 
the interface block 201, which then outputs the 
isochronous packets as also instructed by thecom- 
munications manager 1502. 

20 The procedure in node A for stopping the 

isochronous transmission is described next. Fig. 16 
is a flow chart of the operation of the communica- 
tions manager 1502 in the control block 203 of 
node A. When node A is transmitting via isoch- 

25 ronous transmission, the communications manager 
1502 in the control block 203 of node A monitors 
whether a stop output request has been received 
from another node (step 2001), such as from node 
B. When the node A interface block 201 receives 

30 from another node (node B in this example) via 
asynchronous transmission an asynchronous pack- 
et containing a stop output request, it notifies the 
communications manager 1502 that a stop output 
request was received from node B. 

35 When the communications manager 1502 thus 

determines in step 2001 that a "stop output re- 
quest" was received, it determines in step 2002 
whether output can be stopped. This determination 
can be entrusted to the user, but it is also normally 

40 possible to make this determination by determining 
whether there is any device inputting the AA/ data 
being output by node A. To enable this, it is 
necessary for any nodes inputting A/V data from' 
any other node to request the node outputting that 

45 A/V data to not stop A/V data output. If it is. deter- 
mined in step 2002 that output cannot be stopped, 
the communications manager 1502 instructs the 
interface block 201 to notify node B that the stop 
output request . is rejected (step 2005), and the 

50 interface block 201 so notifies node B by asyn- 
chronous transmission. Node A therefore does not 
stop outputting. 

If, however, it is determined in step 2002 that 
output can be stopped, the interface block 201 and 

55 A/V signal processing block 202 are instructed to 
end the isochronous, transmission. The interface 
block 201 therefore stops isochronous packet out- 
put as instructed by the communications manager 

11 
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1502, and the A/V signal processing block 202 
stops outputting the real-time data to the interface 
block 201 as likewise instructed (step 2003). 

The communications manager 1502 then in- 
structs the interface block 201 to notify node B of j 
the bandwidth used by node A (step 2004), and the 
interface block 201 so notifies node B by asyn- 
chronous transmission. 

It is therefore possible by the present embodi- 
ment to switch the transmitter node from one node / 
(A) to another node (B) by the user operating only 
node B, and when the bandwidth used by nodes A 
and B is the same, it is not necessary for nodes A 
and B to communicate with the bus manager, 
thereby reducing bus traffic. 7i 

A data transmission method according to the 
fourth embodiment of the present invention is de- 
scribed below. The fourth embodiment of a data 
transmission method according to the present in- 
vention relates to a means for switching the isoch- 2t 
ronous transmitter node from node A to node B. 
When isochronous transmission is continued with 
node B substituted for node A, it is necessary by 
the method of the third embodiment above for 
node B to send a "stop output request" to node A. 25 
If it is determined that node A is unable to stop 
output, node A rejects the stop output request from 
node B and maintains data output. 

By the third embodiment of the invention, it is 
possible for the user to force node A to stop data 30 
output and instruct node B to begin output when it 
is necessary for the user to force the transmitter 
node to switch from node A to node B. When node 
A thus receives a stop output command from the 
user, node A must release the Broadcast channel 35 
and used bandwidth by asynchronous transmission 
with the bus manager. It is also necessary for node 
B to obtain from the bus manager by asynchronous 
transmission the Broadcast channel and the band- 
width to be used by node B as commanded by the 40 
user. 

As a result, when node A sends a stop output 
rejection notice to node B, the : user must operate 
both node A and node B, and both node A and 
node B must communicate with the bus manager 45 
by asynchronous transmission. 

The fourth embodiment of the invention is de- 
scribed below,, referring first to the procedure 
whereby node B starts isochronous transmission. 

Fig. 17 is a flow chart of the operation of the so 
communications manager .1502 in the control block 
203 of node B. This flow chart differs from that of ' 
the third embodiment shown in Fig. 15 in that steps 
2101 and 2102 are further added, which are for the 
operation taken when a stop request rejection is 55 
received from node A in step 1904. When a stop 
request rejection is received by node B. or when 
the "used bandwidth" is not received by node B, it 



is determined whether output from node A should 
be forcefully stopped in step 2101. This determina- 
tion is made by the user, and is communicated to 
the communications manager 1502 via the com- 
mand interpreter 1501. If it is not determined to 
forcefully stop node A output in step 2101, output 
by node B using the Broadcast channel does not 
occur. 

When it is determined irustep 2101 to force- 
fully stop node A output, the communications man- 
ager 1502 instructs the interface block 201 to send 
a "stop output command" to node A (step 2102). 
Note that the stop output command must be output 
within a predetermined period after the stop output 
rejection is received. When node A receives the 
stop output command, it stops output, and notifies 
node B of the bandwidth used for node A output. 
The interface block 201 of . node B then receives an 
asynchronous packet containing the used band- 
width from node A, and forwards this information to 
the communications manager 1502 of node B. After 
executing step 2102, the node B communications 
manager 1502 loops back to step 1904, from which 
control flows to step 1905 because the used band- 
width has been received from node A; operation 
thereafter is the same as described above for the 
third embodiment. 

The procedure in node A for stopping the 
isochronous transmission in this fourth embodiment 
is described next. Fig. 18 is a flow chart of the 
operation of the communications manager 1502 in 
the control block 203 of node A. This flow chart 
differs from that of the third embodiment described 
above (Fig. 16) in that step 2201 is further added, 
that is the operation taken after node B is notified 
in step 2005 that the stop output request was 
rejected. 

In step 2005, the communications manager 
1502 of node A instructs the interface block 201 to 
notify node B that the stop output request is re- 
jected (step 2005), and the interface block 201 so 
notifies node B by asynchronous transmission. The 
communications manager 1502 then monitors for a 
predetermined period of time in step 2201 whether 
a stop output command is received from node B. If 
node B receives a stop output rejection from node 
A, and determines that node A output should be 
forcefully stopped, node B outputs the stop output 
command to node A within the predetermined pe- 
riod of time after receiving the stop output rejec- 
tion. The node A interface block 201 thus receives 
from node B an asynchronous packet containing 
the stop output command, and notifies the commu- 
nications manager 1502 thereof that a stop output 
command was received from node B. 

The communications manager 1502 thus deter- 
mines in step 2201 that a "stop output command" 
was received, and control advances to step 2003; 
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operation thereafter is the same as described 
above for the third embodiment. 

When node B determines that node A output 
should not be forcefully stopped, the stop output 
command is not output within the predetermined 
period of time after the stop output rejection is 
received, the communications manager 1502 deter- 
mines in step 2201 that the stop output command 
was therefore not received, and node A isoch- 
ronous transmission continues. 

By the fourth embodiment of the invention thus 
described, the user is able to stop output from 
node A by operating only node B and not operating 
node A when changing the isochronous transmis- 
sion node from node A to node B, even when node 
A rejects the stop output request from node B. 

The fifth embodiment of the present invention 
is described below. The fifth embodiment relates to 
a method whereby: node A, such as a central 
control device, notifies node B, such as a play 
device, of the channel number "to be used, and 
instructs node B to execute isochronous transmis- 
sion using the assigned channel number; and node 
A notifies node C, such as a monitor device, of the 
channel number to be used, and instruct node C to 
receive isochronous packets using the assigned 
channel number from node B. 

If this embodiment was not employed, there 
will be a bus traffic increase, as explained. When 
node A notifies node B of the channel number to 
be used between nodes B and C, and instructs 
node B to execute isochronous transmission be- 
tween nodes B and C, node B negotiates with the 
bus manager via asynchronous transmission to ob- 
tain the specified channel number and the band- 
width to use. When node B successfully obtains 
the bandwidth and channel number, node B begins 
output immediately. If, for example, node B is 
unable to obtain the channel number specified by 
node A, a change of channel number must be 
requested from node A, and bus traffic due to 
communications between nodes A and B in- 
creases. 

The procedure in node A for specifying the 
channel number and issues an output command to 
node B according to this embodiment of the inven- 
tion is described below. Node A issues an output 
command to node B in response to user operation 
of node A. The user command is passed through 
the command interpreter 1501 to the communica- 
tions manager 1502. 

v Fig. 19 is a flow chart of the operation of the 
communications manager 1502 of node A when 
node A specifies the channel number to be used 
between nodes B and C. 

The communications manager 1502 in step 
2301 instructs the interface block 201 to reserve a 
channel number other than the Broadcast channel 



and its bandwidth. More specifically, the interface 
block 201 communicates asynchronously with the 
bus manager as instructed by the communications 
manager 1502 to reserve one open channel num- 

s ber other than the Broadcast channel and the ban- 
dwidth to use, and reports the reserved channel 
number and bandwidth to the communications 
manager 1502. 

The communications manager 1502 then deter- 

io mines in step 2302 whether the channel number 
and bandwidth were successfully reserved; if they 
were obtained, control advances to step 2303. 

The communications manager 1502 then out- 
puts an output command to the interface block 201 

75 causing node B to begin transmitting data through 
the reserved channel number (step 2303). The in- 
terface block 201 thus sends the output command 
and channel number to use to node B via asyn- 
chronous transmission as instructed by the com- 

20 munications manager 1502. 

Similarly, the communications manager 1502 
then outputs an receiving command to the interface 
block 201 causing node C to begin receiving data 
through the reserved channel number (step 2304). 

25 The interface block 201 thus sends the receiving 
command and channel number to use to node C 
via asynchronous transmission as instructed by the 
communications manager 1502. 

The procedure in node B for transmitting data 

30 through the reserved channel number specified by 
node A under isochronous transmission is de- 
scribed next. 

The node B interface block 201 receives an 
asynchronous packet containing the output com- 

35 mand and the channel number to be used between 
nodes B and C. The presence of the output com- 
mand and the channel number to be used are then 
relayed to the communications manager 1502 of 
node B. 

40 Fig. 20 is a flow chart of the operation of the 

node B communications manager 1502 during this 
operation. 

The communications manager 1502 detects 
the output command from node A in step 2401, 

45 and passes control to step 2402 when the output 
command is detected. 

In step 2402, the communications manager 
1502 instructs the A/V signal processing block 202 
to output the real-time data to the interface block 

50 201. The communications manager 1502 then in- 
structs the interface block 201 to execute isoch- 
ronous transmission from node B to Node C using 
the reserved channel number specified by node A. 
The AA/ signal processing block 202 therefore out- 

55 puts the real-time data to the interface block 201, 
which thus transmits the real-time data input from 
the AA/ signal processing block 202 using isoch- 
ronous packets assigned to the channel number 
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specified by node A, according to the instructions 
from the communications manager 1502. 

The procedure in node C for receiving data 
through the reserved channel number specified by 
node A under isochronous transmission is de- 5 
scribed next. 

The node C interface block 201 receives an 
asynchronous packet containing the receiving com- 
mand and the channel number to be used between 
nodes B and C. The presence of the receiving 10 
command and the channel, number to be used are 
then relayed to the communications manager 1502 
of node C. 

Fig. 21 is a flow chart of the operation of the 
node C. communications manager 1502 during this 75 
operation. 

The communications manager 1502 detects 
the receiving command from node A in step 2501, 
and passes control to step 2502 when the receiving 
command is detected. 20 

In step 2502, the communications manager 
1502 instructs the A/V signal processing block 202 
to receive the real-time data to the interface block 
201. The communications manager 1502 then in- 
structs the interface block 201 to execute isoch- 25 
ronous transmission from node B to Node G using 
the reserved channel number specified by node A. 
The A/V signal processing block 202 therefore re- 
ceives the real-time data from the interface block 

201. 

By this embodiment thus described, the node 
outputting the output command and receiving com- 
mand (node A in the present- embodiment) re- 
serves the bandwidth and the channel number to 
be used between nodes B and C. As a result, when 35 
the channel number and bandwidth cannot be re- 
served, asynchronous transmission between nodes 
A and B does not occur. 

Furthermore, when the channel number is 
specified for another node according to the present 40 
embodiment, the reserved channel number will not 
be the Broadcast channel. As a result, nodes other 
than nodes A, * B and Ccan execute isochronous 
transmission using the Broadcast channel as de- 
scribed in the second embodiment of the invention 45 
above. 

The invention .being thus described, it will be 
obvious that the . same may be varied in many 
ways. Such variations are not to be regarded as a 
departure from the spirit and scope of the inven- 50 
tion, arid all < such modifications as would be ob- 
vious to one skilled in the art are intended to be 
included within the scope of the following claims. 

Claims 55 

1. A data transmission method for transmitting 
data requiring real-time processing by isoch- 



ronous packets using a bus from a transmitter 
node to a receiver node, said method compris- 
ing the steps of: 

.assigning a node identifier (1101) to each 
node connected to said bus whenever a bus 
reset occurs; 

adding to said transmitted isochronous 
packets the node identifier of the transmitter 
node transmitting said isochronous packets; 
and 

detecting at the receiver node said node 
identifier from the received isochronous pack- 
et. 

2. A data transmission method according to 
Claim 1, further comprising the steps of: 

generating from said receiver node a con- 
tinue command (step 1401) to continue a first 
operation mode in said receiver node and a 
release command (step 1405) to release the 
first operation mode; 

setting (step 1302), in response to said 
continue command, a protect state in said 
transmitter node to protect a second operation 
mode in said transmitter node from being inter- 
rupted; and 

releasing (step 1304) said protect, state in 
response to said release command. 

3. A data transmission method according to 
Claim 2, wherein said first operation mode is a 
recording mode, and wherein said second opr 
eration mode is a play mode. 

4. A data transmission method according to 
Claim 2, wherein said protected state is reset 
when said bus reset occurs. 

5. A data transmission method according to 
Claim 2, wherein said transmitter node under 
the protect state is protected from an internal 
stop command which is transmitted along the 
bus, but not protected (steps 1312, 1310) from 
an external stop command which is applied 
directly to said transmitter node. 

6. A data transmission method according to 
Claim 2, wherein said transmitter node enters 
the protected state when said continue com- 
mand is input directly to said transmitter node. 

7. A data transmission method for transmitting 
real-time data at least between a first node and 
a second node using a bus for transmitting, 
through one of a plurality of channels, said 
real-time data which is added with a channel 
identifier, said method comprising the steps of: 

reserving a preselected channel by said 
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first node; 

setting a required bandwidth of time to be 
occupied for the preselected channel by said 
first node; 

confirming the reservation of the preselec- 
ted channel with the required bandwidth by 
said first node; and 

transmitting data between said first and 
second nodes using said preselected channel 
with the required bandwidth. 

8. A data transmission method according to 
Claim 7, wherein said preselected channel is a 
Broadcast channel, which is a prefixed chan- 
nel. 

9. A data transmission method for communicating 
real-time data by packets using a bus through 
one of a plurality of channels, said communica- 
tion carried out first by a first node which is 
followed-up by a second node, said method 
comprising the steps of: 

detecting (step 1902) by said second node 
the packets produced from said first node to 
identify the first node; 

sending (step 1903) a "stop output re- 
quest" from said second node to said first 
node; 

detecting (step 2001) said "stop output 
request" by said first node; 

stopping (step 2003) by said first node the 
communication of data through a preselected 
channel when said "stop output request" is 
accepted; and 

starting (step 1906) by said second node 
the follow-up communication of data through 
said preselected channel. 

10. A data transmission method according to 
Claim 9, further comprising the step of reject- 
ing (step 2005) by said first node said, "stop 
output request". 

11. A data transmission method according to 
Claim 9, further comprising the steps of: 

detecting (step 1905) whether or not a 
bandwidth of said preselected channel used by 
said first node is equal to a bandwidth sched- 
uled for use in said second node; and 

changing (step 1907) the bandwidth equal 
to the bandwidth scheduled for use in said 
second node. 

12. A data transmission method according to 
Claim 10, further comprising the steps of: 

sending (step 2102) a "stop output com- 
mand" from said second node to said first 
node; and 



forcibly stopping (steps 2201, 2003) by 
said first node the communication of data 
through a preselected channel even when said 
"stop output request" is rejected. 

13. A data transmission method for transmitting, in 
response to a transmission command pro- 
duced from a control node, real-time data at 
least between a first node and a second node 

10 using a bus for transmitting, through one of a 

plurality of channels, said real-time data which 
is added with a channel identifier, said method 
comprising the steps of: 

reserving (step 2301) a preselected chan- 
15 nel by said control node; 

setting (step 2301) a required bandwidth of 
time to be occupied for the preselected chan- 
nel by said control node; 

confirming (step 2302) the reservation of 
20 the preselected channel with the required ban- 

dwidth by said control node; and 

transmitting (steps 2402, 2502) data be- 
tween said first and second nodes using said 
preselected channel with the required band- 
25 width. 

14. A data transmission method according to 
Claim 13, wherein said preselected channel is 
a channel other than a Broadcast channel, 

30 which is a prefixed channel. 

15. A data transmission system for transmitting 
data requiring real-time processing by isoch- 
ronous packets using a bus from a transmitter 

35 node to a receiver node, said system compris- 

ing: 

means for assigning a node identifier 
(1101) to each node connected to said bus 
whenever a bus reset occurs; 

40 means for adding to said transmitted 

isochronous packets the node identifier of the 
transmitter node transmitting said isochronous 
packets; and 

means for detecting at the receiver node 

45 said node identifier from the received isoch- 

ronous packet. 

16. A data transmission system for transmitting 
real-time data at least between a first node and 

so a second node using a bus for transmitting, 

through one of a plurality of channels, said 
real-time data which is added with a channel 
identifier, said system comprising: 

means for reserving a preselected channel 
55 by said first node; 

means for setting a required bandwidth of 
time to be occupied for the preselected chan- 
nel by said first node; 
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means for confirming the reservation of the 
preselected channel with the required band- 
width by said first node; and 

means for transmitting data between said 
first and second nodes using said preselected 5 
channel with the required bandwidth. 

17. A data transmission system for communicating 
real-time data by packets using a bus through 
one of a plurality of channels, said communica- ;c 
tion carried out first by a first node which is 
followed-up by a second node, said system 
comprising: 

means for detecting (step 1902) by said 
second node the packets produced from said 75 
first node to identify the first node; 

means for sending (step 1903) a "stop 
output request" from said second node to said 
first node; 

means for detecting (step 2001) said "stop 20 
output request" by said first node; 

means for stopping (step 2003) by said 
first node the communication of data through a 
preselected channel when said "stop output 
request" is accepted; and 25 

means for starting (step 1906) by said 
second, node the follow-up communication of 
data through said preselected channel. 
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